DataStax Luna — Support for Open-Source Apache Cassandra. Start a Free 30-Day Trial Now ! Jump to main content DataStax Home Page
• Support
• DataStax Home
• Downloads
• Learn
• Academy
• Community
• Blog
• Resource library
• Examples on GitHub
• Drivers
• Driver home page
• C++ Driver Guide
• C# Driver Guide
• Java Driver Guide
• Node.js Driver Guide
• Python Driver Guide
• Glossary
• world icon English 日本語
• Try for free
• About Cassandra
• What's new
• CQL
• Understanding the architecture
• Planning a deployment
• Installing
• Initializing a cluster
• Security
• Database internals
• Configuration
• Operations
• Backing up and restoring data
• Cassandra tools
• References
• Moving data to/from other databases
• Troubleshooting
• Release notes Search
Can't find what you're looking for? Try searching other guides Apache Cassandra 2.1™ Apache Cassandra 3.0 Apache Cassandra 3.x Apache Cassandra 2.2 Apache Cassandra 2.1 Apache Cassandra landing page All docs
• About Cassandra
Documentation for developers and administrators on configuring, and using the features and capabilities of Apache Cassandra.
• What's new
An overview of new features in Apache Cassandra.
• CQL
Cassandra Query Language (CQL) is the default and primary interface into the Cassandra DBMS.
• Understanding the architecture
Important topics for understanding Cassandra.
• Planning a deployment
Vital information about successfully deploying a Cassandra cluster.
• Installing
Various installation methods.
• Initializing a cluster
Topics for deploying a cluster.
• Security
Topics for securing Cassandra.
• Database internals
Topics about the Cassandra database.
• Configuration
Configuration topics.
• Operations
Operation topics.
• Backing up and restoring data
Cassandra backs up data by taking a snapshot of all on-disk data files (SSTable files) stored in the data directory.
• About snapshots
A brief description of how Cassandra backs up data.
• Taking a snapshot
Steps for taking a global snapshot or per node.
• Deleting snapshot files
Steps to delete snapshot files.
• Enabling incremental backups
Steps to enable incremental backups. When incremental backups are enabled, Cassandra hard-links each memtable flushed to a SSTable to a backups directory under the keyspace data directory.
• Restoring from a snapshot
Methods for restoring from a snapshot.
• Restoring a snapshot into a new cluster
Steps for restoring a snapshot by recovering the cluster into another newly created cluster.
• Recovering using JBOD
Recovering from a single disk failure in a disk array using JBOD.
• Cassandra tools
Topics for Cassandra tools.
• References
Reference topics.
• Moving data to/from other databases
Solutions for migrating from other databases.
• Troubleshooting
• Release notes
How to find the Apache Cassandra release notes.
Recovering from a single disk failure using JBOD
Recovering from a single disk failure in a disk array using JBOD.
How to recover from a single disk failure in a disk array using JBOD (just a bunch of disks).
Node can restart
1. Stop Cassandra and shut down the node.
2. Replace the failed disk.
3. Start the node and Cassandra .
4. Run nodetool repair on the node.
Node cannot restart
If the node cannot restart, it is possible the system directory is corrupted. If the node cannot restart after completing these steps, see Replacing a dead node or dead seed node . If using the node uses vnodes:
1. Stop Cassandra and shut down the node.
2. Replace the failed disk.
3. On a healthy node run the following command:
$ nodetool ring | grep ip_address_of_node | awk ' {print $NF ","}' | xargs
4. On the node with the new disk, add the list of tokens from the previous step (separated by commas), under initial_token in the cassandra.yaml file.
5. Clear each system directory for every functioning drive:
Assuming disk1 has failed and the data_file_directories setting in the cassandra.yaml for each drive is:
-/mnt1/cassandra/data -/mnt2/cassandra/data -/mnt3/cassandra/data Run the following commands:
rm -fr /mnt2/cassandra/data/system $ rm -fr /mnt3/cassandra/data/system
6. Start the node and Cassandra .
7. Run nodetool repair .CAUTION: The node serves stale data until the repair is complete.
8. After the node is fully integrated into the cluster, it is recommended to return to normal vnode settings:
• num_tokens : number_of_tokens
• #initial_token If the node uses assigned tokens (single-token architecture):
1. Stop Cassandra and shut down the node.
2. Replace the failed disk.
3. Clear each system directory for every functioning drive:
Assuming disk1 has failed and the data_file_directories setting in the cassandra.yaml for each drive is:
-/mnt1/cassandra/data -/mnt2/cassandra/data -/mnt3/cassandra/data Run the following commands:
rm -fr /mnt2/cassandra/data/system $ rm -fr /mnt3/cassandra/data/system
4. Start the node and Cassandra .
5. Run nodetool repair on the node. The location of the cassandra.yaml file depends on the type of installation:
Package installations
/etc/cassandra/cassandra.yaml
Tarball installations
install_location/resources/cassandra/conf/cassandra.yaml Restoring a snapshot into a new cluster Cassandra tools
General Inquiries: +1 (650) 389-6000 info@datastax.com
© 2020 DataStax | Privacy policy | Terms of use | Updated: 02 September 2020
Build time: 2020-09-02 08:25:20.729
DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.
Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.
Kubernetes is the registered trademark of the Linux Foundation. cassandra-oss osscassandra21